18장. Google Cloud와 Azure AI 개요

1. AWS만 선택지가 아니다

앞 장에서는 AWS를 기준으로 AI 서비스를 구성하는 방법을 살펴보았다.

AWS에서는 Amazon Bedrock, Lambda, S3, API Gateway, CloudWatch, IAM 같은 서비스를 조합해 AI 기능을 만들 수 있다.
예를 들어 고객 문의 요약 기능은 API Gateway와 Lambda를 통해 Bedrock을 호출하는 구조로 만들 수 있고,
문서 검색 챗봇은 S3 문서 저장소와 임베딩, 벡터 검색, Bedrock을 함께 사용해 구성할 수 있다.

하지만 클라우드 AI를 AWS에서만 사용할 수 있는 것은 아니다.

실무에서는 다음과 같은 선택지가 함께 등장한다.

- AWS 기반 AI
- Google Cloud 기반 AI
- Azure 기반 AI
- OpenAI API 직접 사용
- 오픈소스 모델 직접 운영
- 클라우드 AI와 로컬 AI를 함께 쓰는 하이브리드 구조

이 장에서는 그중 Google Cloud와 Azure AI를 큰 그림으로 살펴본다.

목표는 특정 클라우드의 모든 기능을 외우는 것이 아니다.
개발자가 AI 서비스를 설계할 때 다음 질문에 답할 수 있도록 감을 잡는 것이다.

- Google Cloud의 AI 서비스는 어떤 특징이 있는가?
- Azure AI는 어떤 상황에서 많이 고려되는가?
- AWS, Google Cloud, Azure는 무엇이 다른가?
- 하나의 클라우드에만 묶이지 않으려면 어떻게 설계해야 하는가?

클라우드 AI를 선택할 때는 “어느 회사 모델이 제일 좋은가”만 보면 안 된다.

실제 서비스에서는 모델 성능뿐 아니라 보안, 권한, 비용, 데이터 위치, 기존 인프라, 운영 경험, 조직의 클라우드 전략까지 함께 봐야 한다.

2. Google Cloud의 AI 서비스 개요

Google Cloud에서 AI를 다룰 때 자주 등장하는 서비스가 Vertex AI다.

Vertex AI는 Google Cloud의 머신러닝과 생성형 AI 기능을 통합해서 사용할 수 있게 해주는 플랫폼이다.

쉽게 말하면 Google Cloud 위에서 AI 모델을 사용하고, 배포하고, 관리하기 위한 중심 서비스라고 볼 수 있다.

우리 서비스
→ Vertex AI
→ Google AI 모델 또는 배포된 모델
→ 응답 반환

Vertex AI를 사용하면 텍스트 생성, 임베딩, 이미지 처리, 음성 처리, 모델 학습, 모델 배포 같은 기능을 Google Cloud 안에서 다룰 수 있다.

Google Cloud는 특히 데이터 분석, 빅데이터 처리, 머신러닝 파이프라인과의 연결이 강한 편이다.

예를 들어 다음과 같은 구조를 생각해볼 수 있다.

서비스 로그
→ BigQuery 적재
→ Vertex AI로 분석 또는 분류
→ 결과를 운영 대시보드에 표시

또는 고객 문의 데이터를 분석하는 구조도 가능하다.

고객 문의 데이터
→ Cloud Storage 저장
→ Vertex AI 모델 호출
→ 문의 유형 분류
→ BigQuery에 결과 저장
→ Looker Studio로 리포트 생성

Google Cloud의 장점은 AI 모델만 따로 보는 것이 아니라, 데이터 분석 환경과 AI를 연결하기 좋다는 점이다.

Vertex AI는 Google Cloud에서 AI 모델 사용, 학습, 배포, 관리를 통합적으로 제공하는 플랫폼이다.
생성형 AI뿐 아니라 기존 머신러닝 워크플로우와도 연결할 수 있다.

3. Vertex AI를 사용하는 기본 흐름

Vertex AI를 사용한 생성형 AI 기능의 기본 흐름은 다른 클라우드 AI와 크게 다르지 않다.

사용자
→ 프론트엔드
→ 백엔드 서버
→ Vertex AI
→ AI 응답
→ 백엔드 서버
→ 프론트엔드
→ 사용자

예를 들어 고객 문의 요약 기능을 Google Cloud에서 만든다고 해보자.

관리자가 고객 문의 요약 버튼 클릭
→ 백엔드가 문의 원문 조회
→ 개인정보 마스킹
→ Vertex AI 모델 호출
→ 요약 결과 반환
→ 관리자 화면에 표시

코드 수준으로 단순화하면 다음과 같은 흐름이다.

async function summarizeWithVertexAi(message) {
    const maskedMessage = maskPersonalInfo(message);

    const prompt = `
너는 고객센터 상담 내용을 요약하는 도우미다.

아래 고객 문의를 3문장 이내로 요약해라.

조건:
- 개인정보는 포함하지 않는다.
- 추정하지 않는다.
- 고객이 겪는 문제를 먼저 작성한다.

고객 문의:
${maskedMessage}
`;

    const result = await callVertexAi({
        model: "selected-google-model",
        prompt,
        maxTokens: 300,
        temperature: 0.2
    });

    return result;
}

여기서도 중요한 것은 모델 호출 코드 자체가 아니다.

운영 서비스에서는 다음 처리가 함께 필요하다.

- 사용자 인증
- 권한 확인
- 입력값 검증
- 개인정보 마스킹
- 모델 선택
- 응답 검증
- 비용 추적
- 로그 기록
- 실패 처리

이 원칙은 AWS Bedrock을 쓰든, Google Vertex AI를 쓰든 크게 달라지지 않는다.

클라우드 제공자가 달라져도 AI 서비스의 기본 설계 원칙은 같다.

4. Google Cloud가 잘 맞는 경우

Google Cloud는 데이터 분석과 AI를 함께 쓰려는 경우에 잘 맞는다.

예를 들어 회사가 이미 BigQuery를 많이 사용하고 있다면, AI 기능도 Google Cloud 안에서 구성하는 것이 자연스러울 수 있다.

서비스 이벤트 로그
→ BigQuery
→ Vertex AI 분석
→ 운영 리포트

또는 고객 행동 데이터를 분석하고, 그 결과를 AI 기능에 활용할 수도 있다.

사용자 행동 로그
→ BigQuery
→ 세그먼트 분석
→ Vertex AI로 메시지 생성
→ 사용자별 추천 문구 생성

Google Cloud가 잘 맞는 대표적인 상황은 다음과 같다.

- BigQuery 중심의 데이터 분석 환경을 이미 사용 중이다.
- 데이터 파이프라인과 AI를 함께 구성하려고 한다.
- ML 모델 학습과 생성형 AI를 함께 다루고 싶다.
- 로그, 이벤트, 분석 데이터 기반 AI 기능을 만들고 싶다.
- Google Cloud 기반 인프라와 운영 경험이 있다.

예를 들어 운영 로그 분석 시스템을 생각해보자.

애플리케이션 로그
→ Cloud Logging
→ BigQuery 적재
→ Vertex AI로 장애 패턴 요약
→ 운영자에게 리포트 제공

이런 구조에서는 데이터 저장, 분석, AI 활용이 한 클라우드 안에서 이어진다.

단순히 AI API만 쓰는 것이 아니라 데이터 플랫폼과 AI를 함께 활용할 때 Google Cloud의 장점이 커진다.

5. Google Cloud 사용 시 주의할 점

Google Cloud를 사용할 때도 주의할 점이 있다.

첫 번째는 권한 설계다.

Google Cloud에서도 IAM을 통해 사용자와 서비스 계정의 권한을 관리한다.
AI 기능을 만들 때는 서비스 계정이 어떤 리소스에 접근할 수 있는지 제한해야 한다.

나쁜 예:
AI 백엔드 서비스 계정에 프로젝트 전체 관리자 권한 부여

좋은 예:
필요한 Vertex AI 호출 권한, 특정 Storage 버킷 읽기 권한만 부여

두 번째는 데이터 위치와 보관 정책이다.

AI API로 전송되는 데이터가 어느 리전에서 처리되는지, 로그가 어디에 저장되는지, 입력 데이터가 모델 학습에 사용되는지 확인해야 한다.

세 번째는 비용이다.

Vertex AI 모델 호출 비용뿐 아니라 Cloud Storage, BigQuery, Cloud Logging, 네트워크 비용도 함께 봐야 한다.

예를 들어 로그 데이터를 BigQuery에 계속 쌓고 AI 분석까지 붙이면 다음 비용이 발생할 수 있다.

- 로그 저장 비용
- BigQuery 저장 비용
- BigQuery 쿼리 비용
- Vertex AI 호출 비용
- 결과 저장 비용

네 번째는 서비스 구조가 Google Cloud에 강하게 묶일 수 있다는 점이다.

BigQuery, Vertex AI, Cloud Functions, Cloud Run, Cloud Storage를 깊게 결합하면 편리하지만, 나중에 다른 클라우드로 옮기기 어려울 수 있다.

따라서 중요한 AI 기능은 중간 계층을 두고 추상화하는 것이 좋다.

서비스 코드
→ AI Gateway
→ Vertex AI

이렇게 하면 나중에 필요할 때 일부 기능을 다른 AI 제공자로 전환하기 쉽다.

6. Azure AI와 Azure OpenAI Service 개요

Azure에서 AI를 사용할 때 자주 등장하는 서비스가 Azure AI와 Azure OpenAI Service다.

Azure OpenAI Service는 Microsoft Azure 환경에서 OpenAI 모델을 사용할 수 있게 해주는 서비스다.

쉽게 말하면 OpenAI 계열 모델을 Azure의 보안, 권한, 네트워크, 기업 관리 체계 안에서 사용할 수 있는 방식이다.

우리 서비스
→ Azure OpenAI Service
→ OpenAI 계열 모델
→ 응답 반환

Azure AI는 더 넓은 범위의 AI 서비스들을 포함한다.

- 텍스트 생성
- 문서 분석
- 음성 인식
- 번역
- 이미지 분석
- 검색
- AI Studio 기반 모델 관리

Azure는 특히 Microsoft 생태계와 잘 맞는다.

이미 회사가 다음 환경을 사용하고 있다면 Azure AI를 고려할 가능성이 높다.

- Microsoft 365
- Entra ID
- Teams
- SharePoint
- Azure 인프라
- Microsoft 보안 및 관리 체계

예를 들어 사내 문서가 SharePoint에 많고, 계정 권한이 Entra ID로 관리된다면 Azure 기반 AI가 자연스러울 수 있다.

SharePoint 문서
→ Azure AI Search
→ Azure OpenAI
→ 사내 문서 질의응답

Entra ID는 Microsoft의 ID 및 접근 관리 서비스다.
예전에는 Azure Active Directory라는 이름으로 많이 알려져 있었다.

7. Azure OpenAI Service를 사용하는 기본 흐름

Azure OpenAI Service를 사용한 AI 기능의 기본 흐름도 다른 클라우드와 비슷하다.

사용자
→ 프론트엔드
→ 백엔드 서버
→ Azure OpenAI Service
→ AI 응답
→ 백엔드 서버
→ 프론트엔드
→ 사용자

예를 들어 사내 업무 비서 기능을 생각해보자.

직원이 질문:
"이번 주 배포 일정 요약해줘."

백엔드:
사용자 인증 확인
→ 사용자가 볼 수 있는 일정과 문서 조회
→ Azure OpenAI에 요약 요청
→ 답변 반환

이 구조에서 Azure의 강점은 Microsoft 계정, 문서, 협업 도구와 연결하기 쉽다는 점이다.

예를 들어 다음과 같은 업무 자동화를 생각할 수 있다.

Teams 회의록
→ AI 요약
→ 액션 아이템 추출
→ Planner 또는 Jira 이슈 생성 초안

또는 SharePoint 문서 검색 챗봇을 만들 수도 있다.

SharePoint 문서
→ Azure AI Search 색인
→ 사용자의 질문
→ 관련 문서 검색
→ Azure OpenAI로 답변 생성
→ 출처 표시

Azure OpenAI Service를 사용할 때도 기본 원칙은 같다.

- 사용자가 볼 수 있는 데이터만 AI에게 전달한다.
- 개인정보와 민감 정보는 마스킹하거나 제외한다.
- AI 응답은 중요한 업무에서 초안으로 사용한다.
- 비용과 사용량을 추적한다.
- 모델 응답 실패에 대비한다.

8. Azure가 잘 맞는 경우

Azure는 기업 환경에서 많이 고려된다.

특히 조직이 Microsoft 생태계를 이미 많이 사용하고 있다면 AI 기능을 Azure와 연결하기 쉽다.

Azure가 잘 맞는 상황은 다음과 같다.

- 회사 계정과 권한이 Microsoft Entra ID 중심으로 관리된다.
- 사내 문서가 SharePoint나 OneDrive에 많다.
- Teams를 업무 커뮤니케이션 도구로 사용한다.
- Microsoft 365 기반 업무 자동화를 고려하고 있다.
- Azure 인프라를 이미 사용 중이다.
- 기업 보안과 관리 체계를 Azure 중심으로 운영하고 있다.

예를 들어 사내 AI 문서 검색을 만든다고 해보자.

Microsoft 환경에서는 다음 구조가 자연스럽다.

SharePoint 문서
→ Azure AI Search
→ Azure OpenAI
→ Teams 또는 웹 챗봇

직원은 Teams에서 질문하고, AI는 사용자가 접근 가능한 문서를 기반으로 답변할 수 있다.

직원:
휴가 신청 규정 알려줘.

AI:
사내 인사 규정 문서를 기준으로 답변하고, 관련 문서 링크를 함께 제공.

이때 중요한 것은 SharePoint의 문서 권한과 AI 검색 권한을 일관되게 유지하는 것이다.

사용자가 SharePoint에서 볼 수 없는 문서는 AI 답변에도 사용되면 안 된다.

이 원칙은 AWS, Google Cloud, Azure 모두 동일하다.

9. Azure 사용 시 주의할 점

Azure를 사용할 때도 몇 가지 주의할 점이 있다.

첫 번째는 서비스 이름과 범위가 넓다는 점이다.

Azure AI, Azure OpenAI, Azure AI Search, AI Studio 등 여러 이름이 등장하기 때문에 처음에는 헷갈릴 수 있다.

중요한 것은 각 서비스의 역할을 나누어 이해하는 것이다.

Azure OpenAI Service:
LLM 호출

Azure AI Search:
문서 검색과 색인

Storage:
문서 저장

Azure Functions 또는 App Service:
백엔드 처리

Entra ID:
사용자 인증과 권한 관리

Monitor:
로그와 모니터링

두 번째는 권한과 데이터 연결이다.

Microsoft 365 문서나 SharePoint 문서를 AI와 연결할 때는 기존 문서 권한을 잘 반영해야 한다.

권한 필터 없이 모든 문서를 검색하면 정보 유출이 발생할 수 있다.

세 번째는 비용 구조다.

Azure OpenAI 호출 비용뿐 아니라 검색 인덱스, Storage, Functions, Monitor 비용도 함께 발생할 수 있다.

네 번째는 벤더 종속이다.

Azure AI Search, SharePoint, Teams, Entra ID를 깊게 결합하면 Microsoft 환경에서는 편리하다.
하지만 다른 클라우드로 이동하거나 오픈소스 기반 구조로 바꾸기는 어려워질 수 있다.

따라서 핵심 AI 로직은 특정 서비스에 너무 강하게 묶이지 않도록 설계하는 것이 좋다.

서비스 코드
→ AI Gateway
→ Azure OpenAI

이 구조에서는 나중에 필요하면 AI Gateway 뒤쪽 제공자를 바꿀 수 있다.

10. AWS, Google Cloud, Azure의 차이를 어떻게 볼 것인가

세 클라우드 모두 AI 기능을 제공한다.

하지만 강점과 잘 맞는 상황이 조금씩 다르다.

단순화해서 보면 다음과 같다.

이 표는 절대적인 평가가 아니다.

실제 선택은 조직의 현재 환경에 따라 달라진다.

예를 들어 회사 인프라가 이미 AWS에 있다면 Bedrock을 우선 검토하는 것이 자연스럽다.

EC2, S3, RDS, CloudWatch, IAM을 이미 사용 중
→ Bedrock과 AWS 기반 AI 구성이 운영상 편할 수 있음

반대로 데이터 분석이 BigQuery 중심이라면 Google Cloud가 편할 수 있다.

서비스 로그와 분석 데이터가 BigQuery에 집중
→ Vertex AI와 연결하기 쉬움

Microsoft 365와 Teams 중심으로 업무가 돌아간다면 Azure가 자연스러울 수 있다.

SharePoint 문서와 Teams 업무 흐름 중심
→ Azure OpenAI와 Azure AI Search 연동 고려

중요한 것은 “AI 모델 하나만 보고 클라우드를 선택하지 않는 것”이다.

AI 기능은 결국 데이터, 권한, 로그, 비용, 운영 체계와 연결된다.

11. 멀티 클라우드 AI 전략이 필요한 이유

처음에는 하나의 클라우드 AI로 시작하는 것이 좋다.

하지만 시간이 지나면 여러 AI 제공자를 함께 고려하게 된다.

그 이유는 다음과 같다.

- 모델마다 잘하는 일이 다르다.
- 특정 클라우드 장애에 대비해야 한다.
- 비용이 모델마다 다르다.
- 특정 데이터는 특정 클라우드 밖으로 보낼 수 없다.
- 조직 내 부서마다 사용하는 클라우드가 다를 수 있다.
- 신규 모델이 특정 제공자에서 먼저 출시될 수 있다.

예를 들어 다음처럼 기능별로 다른 모델을 사용할 수 있다.

고객 문의 요약:
저렴하고 빠른 모델

장애 분석:
추론 성능이 좋은 모델

문서 검색 답변:
긴 컨텍스트를 잘 처리하는 모델

코드 리뷰:
코드 이해력이 좋은 모델

민감 정보 처리:
로컬 모델 또는 사내망 모델

이런 구조에서는 하나의 모델이나 하나의 클라우드에 모든 기능을 맡기지 않는다.

요청 기능 확인
→ 데이터 민감도 확인
→ 비용과 품질 기준 확인
→ 적절한 모델 선택
→ 응답 반환

이것을 모델 라우팅 또는 AI Gateway 구조로 볼 수 있다.

서비스 코드
→ AI Gateway
→ AWS Bedrock
→ Vertex AI
→ Azure OpenAI
→ 로컬 LLM

물론 처음부터 멀티 클라우드를 복잡하게 구성할 필요는 없다.

초기에는 하나의 클라우드로 시작하고, 운영 요구사항이 생겼을 때 확장하는 것이 현실적이다.

하지만 처음 설계할 때부터 특정 제공자에 너무 강하게 묶이지 않도록 주의하는 것이 좋다.

12. 벤더 종속을 줄이는 설계

벤더 종속이란 특정 클라우드나 서비스에 너무 강하게 의존해서 나중에 다른 선택지로 이동하기 어려워지는 상황을 말한다.

AI 서비스에서는 벤더 종속이 쉽게 생긴다.

예를 들어 서비스 코드 곳곳에서 특정 AI 제공자의 API 형식을 직접 사용한다고 해보자.

고객 문의 요약 코드
→ 특정 클라우드 AI API 직접 호출

문서 검색 코드
→ 특정 클라우드 AI API 직접 호출

코드 리뷰 코드
→ 특정 클라우드 AI API 직접 호출

이렇게 되면 나중에 모델 제공자를 바꾸기 어렵다.

좋은 방식은 AI 호출을 중간 계층으로 감싸는 것이다.

서비스 기능
→ AI Gateway
→ AI Provider

서비스 코드는 AI Gateway에 기능 목적만 전달한다.

{
  "feature": "customer_summary",
  "input": {
    "message": "고객 문의 원문..."
  }
}

AI Gateway는 내부에서 어떤 제공자를 사용할지 결정한다.

customer_summary
→ 비용이 낮은 요약 모델 사용

incident_analysis
→ 추론 성능이 좋은 모델 사용

sensitive_log_analysis
→ 로컬 모델 사용

이 구조의 장점은 다음과 같다.

- 모델 제공자를 바꾸기 쉽다.
- 기능별 모델 선택이 가능하다.
- 비용 정책을 중앙에서 관리할 수 있다.
- 로그와 사용량 추적을 공통화할 수 있다.
- 프롬프트 템플릿을 한곳에서 관리할 수 있다.
- fallback 모델을 적용하기 쉽다.

다만 추상화에도 비용이 있다.

처음부터 너무 복잡한 AI Gateway를 만들 필요는 없다. 처음에는 공통 함수나 작은 모듈로 시작해도 된다.

초기 단계:
aiClient.ts에서 제공자별 호출을 감싼다.

확장 단계:
AI Gateway 서비스로 분리한다.

운영 단계:
모델 라우팅, 비용 제한, 감사 로그, fallback까지 포함한다.

핵심은 서비스 코드가 특정 모델 API에 직접 강하게 묶이지 않도록 하는 것이다.

13. 클라우드 선택 기준

클라우드 AI를 선택할 때는 다음 기준을 함께 봐야 한다.

예를 들어 이미 AWS를 많이 쓰는 조직이라면 AWS 기반 구성이 운영상 단순할 수 있다.

현재:
EC2, RDS, S3, CloudWatch, IAM 사용 중

선택:
Bedrock 우선 검토

이유:
기존 권한, 로그, 네트워크, 운영 체계와 연결하기 쉬움

반대로 데이터 분석팀이 BigQuery를 중심으로 일한다면 Google Cloud가 더 자연스러울 수 있다.

현재:
서비스 이벤트와 분석 데이터가 BigQuery에 있음

선택:
Vertex AI 우선 검토

이유:
분석 데이터와 AI 모델을 같은 환경에서 연결하기 쉬움

Microsoft 365 기반 사내 업무 자동화를 목표로 한다면 Azure가 적합할 수 있다.

현재:
Teams, SharePoint, Entra ID 사용

선택:
Azure OpenAI와 Azure AI Search 검토

이유:
문서, 계정, 협업 도구와 연결하기 쉬움

즉, 클라우드 AI 선택은 기술 성능만의 문제가 아니다.
조직의 기존 시스템과 운영 방식에 맞아야 한다.

14. 여러 클라우드를 비교할 때 흔한 실수

클라우드 AI를 비교할 때 흔히 하는 실수가 있다.

첫 번째는 모델 성능만 보는 것이다.

"어느 모델이 제일 똑똑한가?"

물론 모델 품질은 중요하다.
하지만 운영 서비스에서는 그것만으로 충분하지 않다.

더 중요한 질문은 다음이다.

- 우리 데이터와 연결하기 쉬운가?
- 권한 관리가 가능한가?
- 비용을 추적할 수 있는가?
- 장애가 났을 때 대체할 수 있는가?
- 로그와 감사 추적이 가능한가?
- 우리 팀이 운영할 수 있는가?

두 번째는 PoC 결과만 보고 운영 결정을 하는 것이다.

PoC에서는 작은 데이터와 적은 요청으로 테스트한다.
하지만 운영에서는 요청량, 비용, 보안, 장애 대응 문제가 커진다.

PoC:
요청 100건 테스트

운영:
하루 요청 100,000건
권한 필터 필요
비용 제한 필요
장애 대응 필요
로그 보관 정책 필요

세 번째는 클라우드별 고유 기능을 너무 빨리 깊게 사용하는 것이다.

처음에는 편리하지만, 나중에 구조를 바꾸기 어려울 수 있다.

네 번째는 보안 검토를 나중으로 미루는 것이다.

AI 기능은 데이터를 외부 모델에 보내는 구조가 많다.
따라서 보안과 개인정보 검토는 개발 후반이 아니라 설계 초기에 해야 한다.

다섯 번째는 비용을 월말에야 확인하는 것이다.

AI 비용은 사용량에 따라 빠르게 늘 수 있다.
처음부터 기능별 사용량과 토큰 사용량을 기록해야 한다.

15. 정리

Google Cloud와 Azure도 AWS와 마찬가지로 AI 기능을 만들 수 있는 강력한 선택지다.

Google Cloud는 Vertex AI를 중심으로 AI 모델 사용, 데이터 분석, 머신러닝 파이프라인을 연결하기 좋다.
특히 BigQuery 중심의 데이터 분석 환경을 이미 사용하고 있다면 AI 기능과 자연스럽게 결합할 수 있다.

Azure는 Azure OpenAI Service와 Azure AI를 통해 기업 환경에서 AI 기능을 구성하기 좋다.
특히 Microsoft 365, SharePoint, Teams, Entra ID를 많이 사용하는 조직에서는 업무 도구와 AI를 연결하기 쉽다.

AWS, Google Cloud, Azure 중 무엇이 가장 좋은지는 상황에 따라 다르다.

중요한 것은 현재 조직의 인프라, 데이터 위치, 권한 체계, 보안 정책, 운영 경험, 비용 구조를 함께 고려하는 것이다.

처음에는 하나의 클라우드로 시작해도 된다.
하지만 장기적으로는 AI Gateway나 공통 AI 처리 계층을 두어 특정 모델이나 클라우드에 과하게 묶이지 않는 구조를 고민하는 것이 좋다.

이 장에서 기억해야 할 핵심은 하나다.

클라우드 AI 선택은 “가장 좋은 모델을 고르는 일”이 아니라,
우리 서비스의 데이터, 권한, 비용, 운영 체계에 가장 잘 맞는 AI 실행 환경을 고르는 일이다.

18장 핵심 요약